home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000212_news@columbia.edu _Wed Jan 3 00:31:54 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id AAA15997 for <kermit.misc@watsun>; Wed, 3 Jan 1996 00:31:50 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id AAA25465 for kermit.misc@watsun; Wed, 3 Jan 1996 00:31:48 -0500 (EST)
  4. Path: news.columbia.edu!panix!bloom-beacon.mit.edu!crl.dec.com!caen!spool.mu.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!usenet.eel.ufl.edu!freenet4.freenet.ufl.edu!afn10375
  5. From: afn10375@freenet4.freenet.ufl.edu (David A. Johns)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times)
  8. Date: 3 Jan 1996 01:41:40 GMT
  9. Lines: 109
  10. Message-ID: <4ccmsk$1pe@huron.eel.ufl.edu>
  11. References: <4bcrfp$lvh@piano.synapse.net> <4bt2qs$ap@gaia.ns.utk.edu>
  12.  <4c1kem$j5r@huron.eel.ufl.edu> <1995Dec29.173301.70177@cc.usu.edu>
  13. NNTP-Posting-Host: freenet4.afn.org
  14. X-Newsreader: NewsWerthy 1.71 (unregistered)
  15.  
  16. In <1995Dec29.173301.70177@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) wrote:
  17.  
  18. #   > Well, I think my vote would go for more functionality in the
  19. #   > scrollback buffers (mark and save, search, buffer input while
  20. #   > viewing the buffer, etc.) and a real plain-text session log
  21. #   > (and yes, I have read the .bwr).
  22. #
  23. #         I guess you mean full editing, and hence a reasonably
  24. #   competant full screen editor to match.
  25.  
  26. Heavens, no.  I say what I mean and mean what I say.  I've never heard
  27. of an editable scrollback buffer, but I do find searching and blocking
  28. for copy very useful.
  29.  
  30. #   The session log is plain-text if that's all the host sends to
  31. #   us. Which means it sends a line of text followed by CR/LF, and
  32. #   no cursor steering, screen embellishments (bold, reverse
  33. #   video, etc), whatnot that make up full screen work rather than
  34. #   glass-tty work. Otherwise our screen is likely decorated
  35. #   semi-randomly as the cursor is moved here and there, and thus
  36. #   what we see isn't the way things arrive or logged.
  37.  
  38. But most other comm programs I've seen save the buffer as plain text,
  39. even if it came through as vtxxx.  I can see some value to being able
  40. to replay the original, especially when there was a lot of screen
  41. manipulation.  But if I can't have both, I'd rather have the plain
  42. text log.
  43.  
  44. > A nice addition to the script language would be a handful of
  45. > user-defined string triggers, like the string that starts automatic
  46. > ZModem downloads in programs that have that (I think NetTerm, a
  47. > winsock program, also watches for the KERMIT READY TO SEND signal and
  48. > starts a download hands-off).
  49.  
  50. #         We've thought about these too. It might help to
  51. #   understand how matters work. Triggers require that MSK buffer
  52. #   bytes entering the terminal emulator, do not act on them, and
  53. #   do parsing of the accumulated stream as each byte arrives. MSK
  54. #   does this for host-triggered printing, and for the APC
  55. #   command. Those commands are well structured, short, and
  56. #   unambiguous (not overlapping any other acceptable commands).
  57. #   So, accumulation/constant reparsing without display and hence
  58. #   bursty screen updates (if any sometimes) turns out to be not
  59. #   what people would accept, nor would I for that matter.
  60.  
  61. Well, Commo has them, and I've never noticed any burstiness.
  62.  
  63. #         We put a lot of thought into the security side too.
  64. #   Whatever happens must be safe and under control of the user;
  65. #   no launch and forget strategy. That means we don't launch
  66. #   external programs based on arbitrary strings arriving. Not
  67. #   only do such strings happen in other circumstances (rather
  68. #   like the Hayes triple + syndrome) but the consequences may not
  69. #   be what the user can live with.
  70.  
  71. A moment of levity is due.  I didn't think of that when I wrote that I
  72. have Commo set to recognize KERMIT*READY*TO*SEND, and as a
  73. consequence, when I tried to read your answer, which quoted the above
  74. line (without the *'s, of course),  I'd find myself in Kermit with
  75. errors accumulating.  I'd exit and Commo would apparently rewrite the
  76. screen, throwing me into Kermit again, and again, and again.  And
  77. Commo had called KERLITE.EXE, so I couldn't just continue the session
  78. in the Kermit emulator.
  79.  
  80. But still, I say let the user beware.  If the strings are
  81. user-selectable, then he doesn't have to turn them on in situations
  82. where there might be danger.
  83.  
  84. #         As mentioned previously, a succession of INPUT
  85. #   statements can gather a succession of "lines", so that
  86. #   facility [access to the input buffer] exists now.
  87.  
  88. Yes, I understand now.
  89.  
  90. > It would be nice to have input that comes in while at the command
  91. > prompt (like when a macro is running or during a transmit) piped back
  92. > into the emulator so that they end up in the log and the buffer.
  93.  
  94.       You have a point. It's not possible presently. I should caution
  95. that INPUT is not always running and hence there are gaps in the INPUT
  96. buffer stream, and that stream wraps in its circular buffer. INPUT material
  97. does go into the session log.
  98.  
  99. #         ? MSK does not run UART chips with hardware parity.
  100. #   Hardware parity is a nice way of not communicating due to
  101. #   differences at each end. MSK uses parity in software and it is
  102. #   highly forgiving during terminal emulation (SET DISPLAY 7/8
  103. #   etc). Furthermore, during file transfers MSK automatically
  104. #   determines parity as much as is possible, and switches to it
  105. #   with a message. I can add code to probe the UART for existing
  106. #   parity, if that would really do a lot of good.
  107.  
  108. Well, I can't imagine that there are many systems out there like the
  109. one I have to deal with.  It was apparently installed and abandoned
  110. under some Texas Instruments contract, and whether the dial-up line
  111. was set at 7o1 by perverse design or by accident, I don't know.  But
  112. while the file transfer mechanism will indeed notice the problem, the
  113. emulator won't.  Most people who tried this system had given up
  114. because they either couldn't log in or their input was mangled, until
  115. I stumbled upon the problem.  No, it's probably not worth changing
  116. now.  I just though that since you do notice some characteristics of
  117. the comm port, why not all of them?
  118.  
  119. #         Wishlists are always welcomed, even though only portions
  120. #   are possible to include in the programs.
  121.  
  122. Glad to hear it.  What's the best place to deliver them?
  123.  
  124. David Johns